A basic concept in the 3GPP Evolved Packet Core (EPC) architecture is the Packet Data Network (PDN). A PDN is an Internet Protocol (IP) network, e.g., the Internet, but it can also be a closed corporate network or an operator service network like an IP Multimedia Subsystem (IMS). A PDN has one or more names associated with it, each name being represented by a string called Access Point Name (APN). A PDN gateway (PDN-GW or PGW) is a functional node that provides access to one or more PDNs. For a description of the relevant background, reference is made to 3GPP Technical Specifications (TS), in particular TS 23.401 and TS 23.402.
A PDN Connection provides a User Equipment (UE) with an access channel to a PDN. It is a logical IP tunnel between the UE and the PGW. Each PDN Connection has a single IP address/prefix. A UE can setup multiple PDN Connections, possibly to the same APN.
In FIG. 1, the network architecture for integrating a Trusted WLAN Access Network (TWAN) 110 into an EPC network is illustrated. FIG. 1 is reproduced from TS 23.402 (rev 12.3.0, FIG. 16.1.1-1) and shows the non-roaming scenario. For roaming scenarios, reference is made to TS 23.402.
The internal architecture of the TWAN 110 is beyond the scope of 3GPP. However, 3GPP has defined a number of functions that need to be supported in the TWAN 110 in order to enable interworking with EPC networks and 3GPP UEs 101. In FIG. 2, also reproduced from TS 23.402 (rev 12.3.0, FIG. 16.1.2-1), TWAN functionality which is required for EPC interworking is illustrated. The required functions are:                A WLAN Access Network (WLAN AN). The WLAN AN includes a collection of one or more WLAN Access Points (AP) 111. An access point terminates the UE's WLAN IEEE 802.11 link.        A Trusted WLAN Access Gateway (TWAG) 112. This function terminates the S2a interface and forwards packets between the UE-TWAG link and the S2a tunnel for that UE and PDN Connection.        A Trusted WLAN Authentication, Authorization, and Accounting (AAA) Proxy (TWAP) 113. This function terminates the STa interface. It relays the AAA information between the WLAN AN and the 3GPP AAA Server 103 or Proxy which is deployed in the 3GPP network (the Home Public Land Mobile Network (HPLMN), in non-roaming scenarios).        
There is a need for information exchange between the different TWAN functions, but since the internal TWAN architecture is beyond the scope of 3GPP, corresponding interfaces are not shown in FIG. 2. The TWAN functions may be implemented in different ways, both co-located as well as separate from each other.
According to 3GPP specifications, there exist two “scenarios” for how PDN Connections can be handled between the UE and the network in the case of TWAN. In the following, these scenarios are referred to as Single-Connection Mode (SCM) and Multi-Connection Mode (MCM).
In SCM, only a single IP session is supported per UE over WLAN. The UE uses the Extensible Authentication Protocol (EAP) to provide information pertaining to what kind of IP session it requests (e.g., by providing an APN).
In MCM, multiple simultaneous IP sessions per UE are supported over WLAN. In this mode, a new control protocol between the UE 111 and the TWAG 112, the WLAN Control Protocol (WLCP), is currently being specified by 3GPP to manage PDN Connections (see, e.g., TS 23.402 and TS 24.244). The WLCP is used to request establishment and disconnection of PDN Connections and to carry parameters associated with each PDN Connection, such as APN, PDN type, and the like. It has been agreed that WLCP is carried over the User Datagram Protocol (UDP)/IP.
A problem of the current solution is that there is no protection of the WLCP signaling between the UE 101 and the TWAG 112. Relying on existing 802.11 air-link protection of traffic, based on IEEE 802.11 standards, is associated with the problems described in the following.
The 802.11 air-link protection only covers the path between the UE 101 and the AP 111. Moreover, it is only based on using the Media Access Control (MAC) addresses of the UE 101 and the AP 111 as identifiers for the traffic. With WLCP, however, traffic is sent between the UE 101 and the TWAG 112, via the AP 111. Since IP packets sent over the 802.11 air-link are protected over the air-link, the UE 101 and the TWAG 112 could potentially authenticate the received WLCP message based on the source MAC address. This solution, however, relies on two assumptions:                The first assumption is that the AP 111, and the link between the AP 111 and the TWAG 112, are secure. If this is the case, it can be assumed that packets cannot be tampered with between the UE 101 and the TWAG 112 even if only the UE-AP link is integrity protected.        The second assumption is that the receiver can authenticate the packet based on the source MAC address.        
The first assumption may hold in many cases, e.g., in operator deployed WLAN/WiFi networks. However, even in that case, the link between the AP 111 and the TWAG 112 may be accessible to third parties and difficult to protect from physical access.
The second assumption relies on that the receiver of the WLCP packet can use the MAC address to identify the sender of the message. In many systems, e.g., regular UE implementations of UDP clients, the MAC address is not available to a UDP application. Therefore, the WLCP software in the UE will not know the MAC address used to carry the message. Whilst it can be argued that this is an implementation issue since lower layers in the UE could pass the source MAC address to the higher (i.e., UDP) layers, this is a significant requirement to put on all operating systems, such as Android, iOS, and the like, and hampers deployment of WLCP.